Part 36: Visual Cortex

Part 36 - Visual Cortex

=== Trash World Inbox ===

Last time, I destroyed Snaxnet's nuclear centrifuges, with high scores of 198, 44 and 7.

Let's see what improvements the thread came up with.

Yeah. This code needs some repetition because of the hardcoded register addresses. By having each REPL check if its value is the highest you can get more parallellism than with my solutions.

silentsnack then had several more speed improvements, starting with this one.
XA does some comparisons and based on that jumps into one of the branches. It uses the final T value to craft a specific value to send on M, which is used in MODI instructions in XB to send a zero to the exact right centrifuge. XA also uses the T value to decide how many cycles it needs to wait before XB is done. XB uses X to kill itself after shutting down all centrifuges, while XC shuts down XA more quickly than it could itself.

This 75 cycles solution works somewhat similarly to the previous one. Now, XA is responsible for turning off the centrifuges. The main reason this is so fast is because XB puts a REPL of itself in each centrifuge host, with the T timers exactly synced such that all of them trigger the COPY 0 #POWR simultaneously, just barely after the 4th centrifuge is turned off. XA knows to stop after four rounds too, so you skip checking which centrifuge is the final remaining one.

This final improvement consists of a bunch of smaller optimizations of the previous solution, in exchange for harder to read code. Most notably, calculating the delay countdown has been removed in favour of variable delay timing caused by specific jumps. Also, XB is now responsible for stopping XA after shutting down 4 centrifuges.


silentsnack also improved the low lines solution.

Only having one #ZGC instance doesn't reduce the number of lines - the @REP gets unrolled. But it does make for much cleaner code, I agree. This code is neat in its simplicity. It writes the values into a file, and then finds the largest value in that file. To keep the code short it has to recheck some old values in the file, but once the TEST EOF is true, X has the largest value. By testing how many steps that value sits from the start of the file you know which centrifuge you need to disable. Then LINKing back by using REPLs to check if we're in the host with link id 799 yet, and a clever use of a DIVI to shut down the EXA if the highest value of all registers is 0 and that's all we need.


=== Mitsuzen HDI-10 - Visual Cortex ===

So, the part about the world not being real...
I think maybe they were onto something.



Two votes this time, one for "That's ridiculous" and one for "Not you, too". I'll roll a die to break the tie.

Not you, too...

They didn't have the right idea about how to deal with it, of course, but...
There's something I've been suspicious about for a while now.
I'm going to have to do some more tests.





My eye is acting up. Must be the phage spreading...

More phage problems, huh?
There's a rumor that the phage originally came from a research lab...
A human-machine interface experiment that found its way into the wild.



Two votes for the same option.

Can we talk about this after I fix my eye?

It's just funny...
I remember some of that research.
It was happening right next door to us.

"Us?" Where do you come from?


OST: EXA Power

The assignment:
- Read a value from each of the optic nerves present and write the correct value to the nerve that runs deeper into your visual cortex (V-CTX). To determine the value that should be written, count the number of values read that are greater than -55, multiply that count by 5 and then subtract 75. Repeat ad infinitum.
- It is not necessary to leave no trace. Your EXAs should be written to operate indefinitely.
- For more information see "Debugging the Phage" in the first issue of the zine.

Alright, to do this I'll certainly need an EXA in each host that has a nerve. Let's first get them out there.

This is a decently clean way to do that. I move the main EXA northeast, while REPLing a GORIGHT one in each host. Those will each create a reader and then make right-going REPLs in a loop. By choosing this order I can also drop in a REPL WRITER to get an EXA in the visual cortex as well.

The VOID Ms which I used to pause the EXAs now need to be replaced by real code. A naive approach might look like this.

Sending the count of values that meet a condition is easy, just add up the results from T. But can you see why this code won't work? It's because the READERs aren't waiting for anything, so the first reader will be sending again before the writer has polled all the readers. You get incorrect, messy data.

There's a lot of ways to solve this. Let's start with a way that keeps the code at minimal Activity, even if it's slow.

All that's needed to make everything line up again is a wait loop in the READER. 453/34/10



Today we're battling top percentiles of 334, 27 and 10.

To get the size down to 29, I can roll up that ADDI loop, using T as a counter. Also, that multiply-by-five step can be done when sending T to M.

This low cycle solution is much slower, at 934/29/10.


To make a faster solution, I first tried to see if I can have a row of EXAs traverse the grid like lemmings, each one reading every value in turn, so that you can basically write to the visual cortex every cycle. That's not possible - the incoming #NERV registers don't get a new value until after a write to the visual cortex, not after a read like in many other assignments. That fact makes the puzzle much harder.

That means that if I want to use parallelism with the bottleneck being that single write, I need to get the data from all those nerves to the writer EXA as fast as possible. The best way to do that seems to optimize M.

As we've seen in earlier updates, one way to do so is to send two data points with one M call. Since an M call takes two cycles, if you can do this without wasting another cycle somewhere it will always be faster than sending a single data point with one M call.


So I need to make one EXA responsible for at least two nerves. I tried a whole bunch of different designs. For example, you could have 3 reader EXAs, each responsible for an entire row of 3 nerves. That solution wasn't any faster than what I already had.
Another design would be to have each EXA responsible for 2 nerves. Of course, with 9 nerves that won't quite work out.

I guess you could have 4 EXAs, each responsible for two nerves, and then a 5th one responsible for both reading the last nerve and writing. However, if you try you will run into a topological issue. It's not possible to divide the tiles of this grid, including the visual cortex nerve, into adjacent pairs. So one EXA would have to walk further for no reason. It's possible the result is still faster than what I have now but I didn't try.

Instead I decided to divide the responsibilities as such:


Even though an EXA responsible for 3 nerves seems slower, I figured I could get away with using one of these because it isn't possible for all of them to send on M at once anyway.

392/50/304

And it works. The LRLOOP handles the EXAs that have two nerves, the OLOOP is for the three nerves one. At the start, the bottom-most LR EXA jumps to SYNC where it waits a bit. If I don't do that, it keeps trying to send early and I have to make all EXAs wait every cycle. Wasting a couple cycles at the start to make it sync up seems the better plan here.

After sending, both the LRLOOP and OLOOP take their EXAs back to their starting hosts and the whole process repeats. Those NOOPs in the LRLOOP are necessary to keep it in sync with the OLOOP.

Is there a way to speed up the OLOOP? Well, it'd be tight but what if that EXA goes back and forth, reading both ways?

A single NOOP is needed before OLOOP starts reading again, so that the WRITER has time to finish up. That same cycle is wasted after the return by the JUMP OLOOP. This change also means both the initial SYNC and the NOOPs in the LRLOOP change to keep things synced up.

And... this code runs at 334/54/245. That is top percentile speed.

I think that is enough for this week. I wouldn't be surprised if an even lower speed is possible and I know a cycle count lower than 29 is possible, but that's for the thread.


Hopefully this is the last time you'll have to hack yourself like this.



The first vote, if it pleases you.


[deadlock] perfect

Nivas?? What are you doing there?



Anyway, I got a visitor.



It's Ghast. He looks different without his sunglasses.

Hey...
You hanging in there?
I just wanted to check up on you.
There's... no new issue of the zine yet.
It's going to be a while before I get it together.

Ghast pauses for a moment and takes a deep breath.

To be honest, I'm not sure if it'll happen.
It's getting harder for me to concentrate, and...
Well, let's not talk about that.
I just hope I was able to educate some people, you know?
Give them some power, some agency...
Otherwise we're all at the mercy of these big systems. You know my speech on this, but I can't help it man.
They're going to run right over our humanity. It's happening faster than we can handle, and soon...

Ghast's voice became quite agitated for that line. He sounds scared, or angry, or both...

Soon... it's all gonna be one big machine.
Hm. I've depressed myself again.
Listen, I'm glad to know you.
We had some good times, back in the day.
Alright. I'm gonna go before I get too sentimental.
See you around somewhere.
I'm out.

I can hear Ghast walking down the hall slowly.
Will this be the last time I see him?
There was an edge to his voice...



The dataphones were cute, but I still need more computing power.
We need to get me some significant hardware upgrades.



This is the vote for next time's intro.